home *** CD-ROM | disk | FTP | other *** search
/ Nebula 2 / Nebula Two.iso / Documents / Other / multiprocessor.txt < prev    next >
Text File  |  1995-06-12  |  3KB  |  59 lines
  1.  
  2. From: mnp!mpaque@NeXT.COM (Mike Paquette)
  3. Newsgroups: comp.sys.next.hardware
  4. Subject: Supporting multiprocessor platforms under NEXTSTEP
  5. Date: 19 Oct 1994 16:18:17 -0500
  6. Reply-To: mnp!mpaque@NeXT.COM
  7.  
  8. Watching the recent thread of discussion "Re: Dual Pentium and
  9. NeXTStep?" is rather like watching a game of telephone, with
  10. information mutating from one message to the next.  I can't stand it
  11. anymore...
  12.  
  13. Here's some real information, from press releases, speeches by
  14. assorted officers of NeXT, and whatnot.  Nothing here that can't be
  15. found out by anyone willing to do a little research.
  16.  
  17. 1) The NEXTSTEP Mach kernel is based on Mach 2.0, with a number of
  18. enhancements picked up from Mach 2.5.  The Mach kernel in NEXTSTEP
  19. 3.3 will incorporate additional enhancements from Mach 3.0,
  20. particularly in the areas of scheduling and messaging.
  21.  
  22. 2) The Mach kernel is designed to work in a symmetric multiprocessor
  23. environment.  There are two areas that need to be addressed to
  24. implement SMP support (along with several hundred details...).
  25.  
  26. First, the kernel must be compiled for use with multiple processors.
  27. This causes mutex locks to be compiled into the kernel to serialize
  28. access to critical sections. That's the easy part.
  29.  
  30. Second, the machine-dependent code needed to manage multiprocessor
  31. initialization, resource management, thread migration, and whatnot
  32. needs to be written.  There is a C language API in the Mach kernel
  33. that covers most of the machine dependencies.
  34.  
  35. In the case of the Intel platforms, this gets tricky, as there are
  36. now FOUR different specifications kicking around for SMP board
  37. design.  There are two versions of the Intel-led SMP consortium's
  38. spec, another multi-vendor spec, and even a spec from a consortium of
  39. chip set manufacturers.  Three of these specifications have actually
  40. been implemented in hardware to varying degrees.
  41.  
  42. 3) The AppKit is not thread-safe (not even on the old m88k and 601
  43. SMP prototype hardware Mr. Jobs and others have mentioned).  Oh, it's
  44. been thought about, but fundamentally the AppKit is an inappropriate
  45. candidate for multithreaded operation.  The degree of interlocking
  46. required would effectively serialize the entire kit, with no
  47. performance gain (in fact, a net loss!) over the current kit.  Think
  48. of the AppKit as a set of tools used to manipulate the global state
  49. of a GUI, and you may see what I mean.
  50.  
  51. In general, I think a developer's time and energy would be better
  52. spent decoupling the application's GUI and core functionality,
  53. permitting the GUI to run in one thread, and the core functionality
  54. torun in one or more other threads (or even on a fast back-end
  55. processor through PDO).
  56.  
  57.          Mike Paquette
  58. =====
  59. I don't speak for NeXT, and NeXT doesn't speak for me.